# Chapter 11. Customizing Your X Environment

#### Contents:

Basics of X Customization
The fvwm Window Manager
The K Desktop Environment
X Applications

In the last chapter, you learned how to set up the X Window System so that it recognizes your graphics board and your monitor. While this is clearly necessary, it is of course only one half of the story. In this chapter, we will tell you the other half: customizing your X environment. Unlike the hardware setup that you normally do only once for a particular computer, you might want to change your work environment from time to time because your work habits have changed, because new and better environments are available, or simply because the old one has become boring for you. Some of these environments are quite sophisticated. For examples they let you start up a program with all the options you want at the press of a key or the click of a mouse, they let you drag file icons onto a printer to have text printed, and they can do lots of other fancy things.

Today, many distributions more or less automatically configure your X server for you and put you into a graphical environment from the start. However, if things go wrong during installation and you want to fine-tune your X server (in order to achieve a higher resolution, for example) or if you simply want to use another windowing environment than the one your distribution vendor has selected as the default, we'll tell you what to do.

We will first tell you the basics of configuring X, including what happens at startup, what X resources are, and how you can use them. In principle, this is already enough to configure X for use, but if you are anything more than a Spartan, you demand more from your work environment. We will therefore tell you how to configure a work environment based on the `fvwm` window manager first. For a long time, `fvwm` was the favorite window manager among Linux users, and only recently other window managers and desktop environments have taken the lead.

Until recently, the problem with using X on Unix systems in general and Linux in particular was that nothing was integrated. You would use a window manager and a number of X applications, but they would all look different, behave differently, and operate in a manner that was not integrated. For example, drag-and-drop-- ubiquitous on Windows or the Macintosh--was hardly heard of on Linux, and if it was, it was difficult to find two applications that could interact together with drag-and-drop.

A relatively new category of software, the so-called desktop environments, has accepted the challenge to produce a state-of-the-art Unix GUI and tries to provide an integrated, consistent desktop where all programs have the same look-and-feel, behave the same, and even provide the same menus in all applications (to the extent where this is possible).

Currently, there are two main desktop environments available for Linux, the K Desktop Environment and GNOME. KDE is a little bit older and much more advanced with respect to functionality and stability. It aims at making people coming from other computing environments feel at home, as well as providing long-term Unix users a more productive and friendly work-environment. GNOME, on the other hand, has put a lot of work into the visual aspects of a desktop environment with colorful icons and the like, but it is still lacking stability and a number of features. Therefore, we will cover KDE here.

The Red Hat, SuSE, and Caldera releases include both KDE and GNOME, while Debian includes only GNOME. You can also find more about GNOME at http://www.gnome.org. Appendix B reprints an article describing the design of that desktop.

## 11.1. Basics of X Customization

Before running X applications, it's a good idea to learn the rudiments of X customization, so that you're not forced to live with the (often unappealing) default configuration used on many systems.

### 11.1.1. xinit

You run X with the `startx` command. This is a frontend (passing in reasonable options) for `xinit`, the program responsible for starting the X server and running various X clients that you specify. `xinit` (via `startx`) executes the shell script .xinitrc in your home directory. This script merely contains commands that you wish to run when starting X, such as `xterm`, `xclock`, and so on. If you don't have a .xinitrc file, the system default /usr/lib/X11/xinit/xinitrc is used instead.

Here, we'll present a sample .xinitrc file and explain what it does. You could use this as your own .xinitrc or copy the system default xinitrc as a starting point:

>     1  #!/bin/sh
>     2  # Sample .xinitrc shell script
>     3
>     4  # Start xterms
>     5  xterm -geometry 80x40+10+100 -fg black -bg white &
>     6  xterm -geometry -20+10 -fn 7x13bold -fg darkslategray -bg white &
>     7  xterm -geometry -20-30 -fn 7x13bold -fg black -bg white &
>     8
>     9  # Other useful X clients
>     10 oclock -geometry 70x70+5+5 &
>     11 xload -geometry 85x60+85+5 &
>     12 xbiff -geometry +200+5 &
>     13 xsetroot -solid darkslateblue &
>     14
>     15 # Start the window manager
>     16 exec fvwm2

This should be quite straightforward, even if you're not familiar with X. The first two lines simply identify the shell script. Lines 5-7 start up three `xterm` clients (recall that `xterm` is a terminal-emulator client). Other clients are started on lines 10-13, and on line 16 the window manager, `fvwm`, is started.

Running `startx` with this particular .xinitrc in place gives you something that looks like Figure 11-1.[43]

> [43]All right, so it's not a work of art, but we needed something simple that would work correctly on most displays!

#### Figure 11-1. Screen created by sample .xinitrc file

Let's look at this in more detail. On line 5, we see that `xterm` is started with several options, -geometry, -fg, and -bg. Most X clients support these standard options, among others.

The -geometry option allows you to specify the size and position of the window on the display. The geometry specification has the format:

>     xsizexysize+xoffset+yoffset

In this case, the option -geometry 80x40+10+100 puts the window at the location (10,100) on the screen (where (0,0) is the top-left corner), making it 80 characters wide by 40 characters high. Note that `xterm` measures the size of the window in characters, not pixels. The actual size of the window in pixels is determined by the font that is used.

The -fg and -bg arguments allow you to specify the foreground (text) and background colors for the `xterm` window, respectively. The colors used here are a rather boring black and white, but this should work on color and monochrome displays alike. Under X, colors are usually specified by name, although you can provide your own RGB values if you prefer. The list of color names (and corresponding RGB values) is given in the file /usr/lib/X11/rgb.txt. Running `xcolors` will display these colors, along with their names.

Line 6 runs another `xterm`, although the arguments are slightly different:

>     xterm -geometry -20+10 -fn 7x13bold -fg darkslategray -bg white &

First of all, the geometry specification is just `-20+10`. Without size parameters, `xterm` will use the default, which is usually `80x25`. Also, we see that the xoffset is prefixed with a `-`, instead of `+`. This places the window 20 pixels from the right edge of the screen. Likewise, a geometry specification of `-20-30` (as used on line 7) means to place the window 20 pixels from the right edge of the screen and 30 pixels from the bottom. In this way, the placement of windows is less dependent on the particular resolution you're using.

The -fn option on lines 6 and 7 specifies that the font used by `xterm` should be `7x13bold`. Using the command `xlsfonts` displays a complete list of fonts on your system; the X client `xfontsel` allows you to select fonts interactively--more about fonts later.

On line 10 we start an `oclock` client, which is a simple analog clock. Line 11 starts `xload`, which displays a graph of the system load average (number of running processes) that changes with time. Line 12 starts `xbiff`, which just lets you know when mail is waiting to be read. Finally, on line 13 we do away with the bland grey X background and replace it with a flashy darkslateblue. (Fear not; there is more fun to be had with X decor than this example shows.)

You'll notice that each of the X clients started on lines 6-13 is executed in the background (the ampersand on the end of each line forces this). If you forget to put each client in the background, `xinit` executes the first `xterm`, waits for it to exit (usually, after you log out), executes the next `xterm`, and so on. The ampersands cause each client to start up concurrently.

What about line 16? Here, we start `fvwm` (Version 2), a window manager used on many Linux systems. As mentioned before, the window manager is responsible for decorating the windows, allowing you to place them with the mouse, and so forth. However, it is started with the command:

>     exec fvwm2

This causes the `fvwm2` process to replace the `xinit` process. This way, once you kill `fvwm`,[44] the X server shuts down. This is equivalent to, but more succinct than, using the Ctrl-Alt-Backspace key combination.

> [44]If you have experimented with `fvwm`, you'll notice that pressing the first mouse button while the cursor is on the background causes a menu to pop up. Selecting the Quit fvwm option from this menu causes `fvwm` to exit.

In general, you should put an ampersand after each X client started from .xinitrc, and `exec` the window manager at the end of the file. Of course, there are other ways of doing this, but many users employ this technique.

If you read the manual pages for `xterm` and the other X clients, you'll see many more command-line options than those described here. As we said, virtually everything about X is configurable. `fvwm` (Version 2) uses a configuration file of its own, .fvwm2rc, described in its manual page. (If you have no .fvwm2rc file, the system default /usr/lib/X11/fvwm2/system.fvwmrc is used instead.) The manual pages, as well as books on using X (such as X Window System User's Guide by Valerie Quercia and Tim O'Reilly), provide more information on configuring individual clients.

### 11.1.2. The X Resource Database

Depending on which environment you use, you can't use X for long without running into X resources; they are mentioned in virtually every manual page. X resources provide a more flexible and powerful way to configure X clients than using command-line options such as -geometry and -fg. They allow you to specify defaults for entire classes of clients; for example, we could set the default font for all invocations of `xterm` to `7x13bold`, instead of specifying it on each command line.

Recently, X resources have fallen out of favor with X developers. While they are really very flexible, they are not particularly easy to work with and feel more like a relic of ancient times. A growing number of programs are therefore customized not by X resources but instead via comfortable configuration dialog boxes. However, it still pays to know about X resources because you will come across them for a long time to come.

Using X resources requires two steps. First, you must create a file containing your X resource defaults. Typically, this file is called .Xdefaults and lives in your home directory. Second, you need to use `xrdb` to load the X resources into the server, which makes them available for use. In general, you run `xrdb` from your .xinitrc before starting any clients.

As a simple example, let's take the various command-line options used by the clients in the earlier sample .xinitrc and specify them as X resources instead. Afterwards, we'll show you what kinds of changes need to be made to .xinitrc to make use of the resources.

First a few words about resources and how they work. Each X application is part of a certain application class. For example, `xterm` is a member of the `XTerm` class. `xclock` and `oclock` are both members of the `Clock` class. Setting resources for the `Clock` class affects all applications that are part of that class; because `xclock` (a square analog clock) and `oclock` (an oval analog clock) are similar, they belong to the same class and share the same resources. Most applications are members of their own exclusive class; `xload` is the only member of the `XLoad` class. However, if another `xload`-like application were to be written, it might be part of the `XLoad` class as well. Placing X clients into application classes allows you to set resources for all applications in that class. (The manual page for each X client specifies the application class the client belongs to.)

Standard X clients employ resources such as `foreground`, `background`, `geometry`, and `font`. Also, many X clients have specific resources of their own; for example, `xterm` defines the resource `logFile`, which allows you to specify a file in which to log the terminal session. Again, the manual pages for X clients specify which resources are available.

Moreover, resources themselves are arranged into a hierarchy of classes. For instance, the `background` resource is a member of the `Background` class. Resource classes allow many separate resources to be members of the same class, for which you can set resource values for the class as a whole. For example, the `background` resource usually determines the primary background color of a window. However, if an application window has several panels or regions, you may wish to set the background for each panel separately. There might be resources such as `background1`, `background2`, and so on, for each panel, but they would all be members of the `Background` resource class. Setting the resource value for the `Background` class sets the value for all resources in that class.

In general, you won't need to concern yourself with the differences between resource classes and the resources within that class. In most cases, it's easier to set resource values for an entire class (such as `Background`) instead of individual resources in that class.

Now, let's look at how resource values are set in the X resource database. A complete resource specification is of the form:[45]

>     (ApplicationClass|applicationName)*(ResourceClass|resourceName) : value

The vertical bar means "choose one or the other." Let's say you want to set the background color of an `xterm` window. The complete resource specification might be:

>     xterm*background: darkslategray

However, this sets only a particular background resource (not all of the resources that might be in the `Background` class) and only for the `xterm` client when it is invoked as `xterm` (more on this later). Therefore, we might want to use resource classes instead:

>     XTerm*Background: darkslategray

This resource specification will apply to all `xterm` clients, and all `Background`-class resources used by `xterm`.

> [45]Actually, resource specifications have a more complex syntax than this, and the rules used to determine resource and value bindings are somewhat involved. For simplification, we are presenting a reasonable model for application resource settings--and we direct curious readers to a good book on using X like the X Window System User's Guide.

Now, let's look at translating the options given in the earlier .xinitrc file into application resources. Create a file in your home directory, called .Xdefaults. For the previous sample .xinitrc, it should contain:

>     1  Clock*Geometry:         70x70+5+5
>     2  XLoad*Geometry:         85x50+85+5
>     3  XBiff*Geometry:          +200+5
>     4
>     5  ! Defaults for all xterm clients
>     6  XTerm*Foreground:       white
>     7  XTerm*Background:       black
>     8
>     9  ! Specific xterms
>     10 xterm-1*Geometry:       80x40+10+110
>     11
>     12 xterm-2*Geometry:       -20+10
>     13 xterm-2*Font:           7x13bold
>     14 xterm-2*Background:     darkslategray
>     15
>     16 xterm-3*Geometry:       80x25-20-30
>     17 xterm-3*Font:           7x13bold

Lines 1-3 set the `Geometry` resource class for the `Clock`, `XLoad`, and `XBiff` application classes. On lines 6-7, we set the `Foreground` and `Background` resource classes for the `XTerm` class as whole. All `xterm` clients will use these values for `Foreground` and `Background` by default.

On lines 10-17, we set resources specific to each invocation of `xterm`. This is necessary because not all of the `xterm`s are alike; they each have different geometry specifications, for example. In this case, we have named the individual `xterm` invocations `xterm-1`, `xterm-2`, and `xterm-3`. As you can see, we set the `Geometry` resource for each on lines 10, 12, and 16. Also, we set the `Font` class for `xterm-2` and `xterm-3`. And we set the `Background` class to `darkslategray` for `xterm-2`.

X resource binding rules work so that certain bindings have precedence over others. In this case, setting a resource for a specific invocation of `xterm` (as in `xterm-2*Background` on line 14) has precedence over the resource setting for the `XTerm` class as a whole (`XTerm*Background` on line 7). In general, bindings for an application or resource class have lower precedence than bindings for particular instances of that class. In this way, you can set defaults for the class as a whole but override those defaults for particular instances of the class.

Now, let's look at the changes required to .xinitrc to use the X resources defined here. First, we need to add an `xrdb` command, which loads the application resources into the server. And, we can get rid of the various command-line options that the resources have replaced. To wit:

>     #!/bin/sh
>     # Sample .xinitrc shell script

>     # Load resources
>     xrdb -load $HOME/.Xdefaults

>     # Start xterms
>     xterm -name "xterm-1" &
>     xterm -name "xterm-2" &
>     xterm -name "xterm-3" &

>     # Other useful X clients
>     oclock &
>     xload &
>     xbiff &
>     xsetroot -solid darkslateblue &

>     # Start the window manager
>     exec fvwm2

As you see, the -name argument given to the three instances of `xterm` lets us specify the application name that `xterm` uses for locating X resources. Most X clients don't support a -name argument; the name used is usually the one which it was invoked with. However, because many users run several `xterm`s at once, it is helpful to distinguish between them when setting resources.

Now, you should be able to modify your X environment to some degree. Of course, knowing how to configure X depends partly on being familiar with the many X clients out there, as well as the window manager (and how to configure it). The rest of this section will present various X applications for Linux. We'll also look at a particular window manager, `fvwm`, in detail.

Copyright © 2001 O'Reilly & Associates. All rights reserved.